wafer.space Community - PRBS31 implementation

Repo here: https://github.com/MichaelBell/prbs31

GitHub - MichaelBell/prbs31: Quick implementation of PRBS31

Quick implementation of PRBS31. Contribute to MichaelBell/prbs31 development by creating an account on GitHub.

5:40 p.m.

Realised we should probably go to a thread to reduce spam

yeah thread good. And no, I am after a power-of-two number of outputs per cycle, probably 32.

5:43 p.m.

the fastest data latches are planned to be quarter the output baudrate; the VCO is supposed to run at half the output baudrate

5:45 p.m.

I'll know more about what those mean in GHz in a few hours when I have drawn some cells and did a bit of PEX on them to see what GBW I can hope for once I include the need for loads and at least some amount of routing parasitics.

5:45 p.m.

the PRBS has to in all cases reliably keep up with the baudrate though.

5:46 p.m.

basically up to where it produces substantial BER at the output data bit latches or such

5:48 p.m.

I think I can hope for approximately 15 Gbit/s tops, I hope 10GBASE-KR is decently practical to hit with some amount of margins overall.

5:49 p.m.

Faster would require inductive peaking throughout many parts of the serializer and I do not have infrastructure for planning/simulating the interactions of so many inductors in close proximity.

OK, I'll keep one more bit to give you the 32 bits. This is using Tholin's 3v3 library, clock report says fmax of 348MHz at the worst corner. So that hopefully won't bottleneck you. (edited)

(I can get about 28 GHz GBW out of the transistors and I only "need" 1.12x the bitrate to theoretically make it behave.... but it'd be unusable without a decent bit of inductive peaking around the final MUX's.)

RebelMike

OK, I'll keep one more bit to give you the 32 bits. This is using Tholin's 3v3 library, clock report says fmax of 348MHz at the worst corner. So that hopefully won't bottleneck you. (edited)

How pessimistic is that estimate? I'm aiming for the tt corner btw.

I would normally say fairly pessimistic, though Tholin's library is not well characterised so it's all a bit finger in the air! nom_tt_025C_3v3 is saying 460MHz

ohhh yeah those numbers I like a good deal more. I assume it could be told to be somewhat faster if that's put as a constraint? Just in case the serializer predictions come to desire a bit more.

5:54 p.m.

also notably I don't care about how it gets initalized it just can't be all-0's.

I can ask but given how simple everything is I don't know whether that would actually change anything. Removing en would probably help if you don't need it.

wait

5:56 p.m.

that code snipped you gave me there, in #🕰️-analog , that only computes one bit per cycle.

5:57 p.m.

I don't need enable the clock feed to that section is from the serializer anyways; what it would possibly want/need is selecting the user input of the digital tt mux instead

5:59 p.m.

This is iirc not the right view of the polynom, but it's an LFSR with vaguely similar tap structure in some view and the correct output width:

module prsg31_stream32 (
    input  wire        clk,
    input  wire        rst,   // synchronous, active-high
    input  wire        en,
    output reg  [31:0] out
);

    reg [31:0] lfsr;

    always @(posedge clk) begin
        if (rst) begin
            lfsr <= 32'hffff_ffff;
            out  <= 32'hffff_ffff;
        end else if (en) begin
            lfsr[31:16] <= lfsr[30:15] ^ lfsr[27:12];
            lfsr[15:4]  <= lfsr[14:3]  ^ lfsr[11:0];
            lfsr[3:1]   <= lfsr[2:0]   ^ lfsr[30:28] ^ lfsr[27:25];
            lfsr[0]     <= lfsr[30]    ^ lfsr[12];

            out[31:16]  <= lfsr[30:15] ^ lfsr[27:12];
            out[15:4]   <= lfsr[14:3]  ^ lfsr[11:0];
            out[3:1]    <= lfsr[2:0]   ^ lfsr[30:28] ^ lfsr[27:25];
            out[0]      <= lfsr[30]    ^ lfsr[12];
        end
    end

endmodule

Ah, you want 32 cycles per clock? That makes sense. I hadn't found a spec - just read wikipedia

It's possible this does the right thing: https://github.com/mgwang37/PRBS/blob/master/Verilog/prbs_generator.v#L336-L372

PRBS/Verilog/prbs_generator.v at master · mgwang37/PRBS

Pseudo-Random Binary Sequence. Contribute to mgwang37/PRBS development by creating an account on GitHub.

RebelMike

Ah, you want 32 cycles per clock? That makes sense. I hadn't found a spec - just read wikipedia

It's possible this does the right thing: https://github.com/mgwang37/PRBS/blob/master/Verilog/prbs_generator.v#L336-L372

I sent you spec from the 802.3

RebelMike

Ah, you want 32 cycles per clock? That makes sense. I hadn't found a spec - just read wikipedia

It's possible this does the right thing: https://github.com/mgwang37/PRBS/blob/master/Verilog/prbs_generator.v#L336-L372

see DM btw for link

Thanks - got it.

6:07 p.m.

I need to go get some food and stuff, I'll be back later. But theoretically that shouldn't slow things down too much I think, just increase area a bit.

6:14 p.m.

This would be the "alternative" pattern genrator thing that would be of some amount of applicable relevance; I don't think it'll be easier/cheaper/faster to do, though.

6:15 p.m.

I'd guess one could hard-set the input to be 1 and then it might not need explicit initializing.

6:16 p.m.

as it might not be vulnerable to lock itself up as the left XOR would act as an invert instead between the output of the right XOR and the input to S0

Basically I'm not that worried that LFSR thing can keep up, it's more that the optional direct input serialization would need to be combined in a way that's not a slowdown. And there's some control bits that need to be provided latched (clock glitches expected if that glitches) to notably adjust the VCO's loads for slow mode. The partial positive feedback has to cause sufficient differential amplitude at the reduced tail current.

6:44 p.m.

But as I said this isn't needed until I have enough progress to suggest that I can get the serializer made in time.

Though, the one notable thing, if you could provide some insight on how large it would be to provide two shifted versions of the parallelized bitstream of whatever is fed to the serializer, for a total of 3 copies that are spaced exactly 1 bit, with two of them optionally inverted, plus some about 10 control bits, that'd be great to know. The final outputs from the digital section to the serializer will be SDR clocked and need to be provided as pairs of bit[I]/not(bit[I]) because they are consumed by differential current mode logic. If it's not too expensive to do those couple control bits and the two optionally-inverted (that'd be control bits that stay in the digital section) single-bit-each shifted stream copies, it might even be realistic to do a 3-tap FIR TX EQ. If it's easy to do those copies I would do them at a faster stage of the MUX as it would be cheaper than so many wide slow speed MUXes to collect them all up to some decent speed. Like, at 8-wide perhaps. Note that we don't have flip flops but we do have two nice symmetric clock phases and the latches we have freely allow phase selection. And MUX2 are also fast and fairly cheap. Especially if their select inputs are driven by CMOS voltage levels. And ofc data inversion is literally free because it's just crossing the wires.

For the shifted version - that should just be wires (plus maybe remembering a couple of bits?), and XORs for the optional inversions are not huge. The main area will be all the flops for the final output from the digital section, I'm not sure what width you're aiming that to be but with 3 versions each in +/- pairs that's going to be the majority. Switching those for latches could help but you'd need the input to the latch to be stable for half the clock cycle so it might reduce fmax. I'm not sure what you mean by ~10 control bits - what are they controlling?

Oh I thought the inversion would be after the storage of the flop.

8:00 p.m.

The 10 control bits would depending on being set or not either connect a tail current cell to a current mirror gate voltage or disconnect from there and instead clamp to GND.

8:00 p.m.

they'd be setting drive current for the non-main taps

8:02 p.m.

If it's possible to do that cheaper after the initial like 2 layers of CML MUX (32->16->8->shift_spawn->4->phase_align->4->MUX2->amplifier->MUX2->PA)

8:03 p.m.

the numbers are parallel latch quantity for a single output tap

Inversion after the flop makes sense, just need to be careful with asymmetric delay.

to an extend, I guess... It'd get latched up pretty much right away though, the one benefit could be if cheap to provide half of them synchronized to the other clock edge to skip a second latch on the CML side to shift appropriately.

8:14 p.m.

I'm bad at estimating the gf180mcuD logic density for now at least

8:15 p.m.

and I've not yet figured out how complex it'd be to do the shifted version at the 8-wide stage in CML instead. Gates to use are level sensitive latches, MUX2, and BUF. Inversions are free.

I got some CI set up, and implemented the 32 iteration unroll thing: https://github.com/MichaelBell/prbs31/actions/runs/27103395235

if you say it's not expensive and will be straight-forward to do I'll just keep that in mind.

You can pretty easily play with that to see what's what, librelane should size the block appropriately. Doing the unroll made basically no difference to size or speed

I just know that last time I tried to understand I kinda got a headache instead of a solution.

8:17 p.m.

C.f. this as reference:

8:18 p.m.

I'm not doing latches at the C2 clock though, that's MUX2/BUF instead

8:19 p.m.

and due to that I can't use this architecture of cooking up a total of 4 taps for nearly free

Interesting - I think I see where you're going - I see why you want the offset streams

8:24 p.m.

those are example settings for the 3 taps btw

https://people.engr.tamu.edu/spalermo/ecen689/lecture7_ee720_eq_intro_txeq.pdf page 16 tooo

8:35 p.m.

can't paste any more screenshots for some reason idk why that's broken, locks my brwoser up for 20 seconds each time I even try

ahhh this works at least

8:44 p.m.

shows the massive difference

https://people.engr.tamu.edu/spalermo/ecen689/low_power_link_lee_jssc_2000.pdf [Lee JSSC 2000]

RebelMike

Interesting - I think I see where you're going - I see why you want the offset streams

If you can tell(/soon show how) doing it at an 8-wide moment would be practical, I'd be quite ears. The 8:4 mux that comes after would want half the input latches at one clock phase and the other half at the inverted clock phase, basically having the input latches transparent exactly while that input side isn't selected by the single-wide MUX2 that particular latch is feeding into. Unfortunately the slower clocks won't be too edge-aligned to the faster ones as they're just made from a pair of latches with opposing clocks who's data is fed back to each other. I think there'll be easy opportunity to at least mint quadrature for some deserving applications as we might as well tap both latches of such a DIV2. Boosting the amplitude into the clock of the primary (fastest) DIV2 is expected to be quite important to make it reliable; the only other place where a 2-level MCML gate (2 series nmos sitting on the tail current source, before the steered tail current gets to see the load resistors) has to operate that fast is the final MUX2 that immediately feeds into the pre-driver (a buffer chain culminating in the digitally-selected-tail-current output driver for that tap; it's basically just a differential pair with the (pull-up) loads being off-chip). And those MUX2 there are fed by boosted MUX2 not by weakly regenerating latches. Like, those second-to-last MUX2 probably get the privilege of quadrature clocks and an output booster (just a single buffer) that should conspire to provide just enough hold time for the final MUX2 to not really feel that. Though I'd probably have to... ehhhh as annoying as it feels, it's probably gonna have to be some semblance of a C4 architecture, now that I manage to fully grasp [Lee JSSC 2000] just having flipped the selection and the data transistor levels by splitting the lower ones in two to move all fan-out the the very bottom. Solves the issue of needing aligned quarter and half rate clocks, by instead using quadrature quarter-rate clocks directly. I guess the good thing is that technically that input-multiplexer itself architecturally doesn't actually need to provide current gain to work. So ensuring it's fed strong and the output is aggressively pre-amplified before it hits the controlled output current PA, should probably suffice to make it work. No more latches driven with what's a DDR clock w.r.t. the output.

@RebelMike Ok I got time off until the deadline.

RebelMike

Interesting - I think I see where you're going - I see why you want the offset streams

Figured out how to do it "scalable" for the C4 architecture....